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Abstract. In this document we share the experiences gained throughout 
the development of a metro system case study. The model is constructed 
in Event-B using its respective tool set, the Rodin platform. Starting 
from requirements, adding more details to the model in a stepwise man- 
ner through refinement, we identify some keys points and available plug- 
ins necessary for modelling large systems (requirement engineering, de- 
composition, generic instantiation, among others), which ones are lacking 
plus strengths and weaknesses of the tool. 
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1 Introduction 

Event-B [1 ] is a formal method that allows modelling and refinement of systems. 
From the experiences during DEPLOY 1 , there exists a natural instinct to model 
a system such that it mimics its implementation. That is not always the best 
approach: models should be used to understand the system and its behaviour; 
the implementation should be seen as an independent task. This document aims 
to guide modellers by describing the experiences gained throughout the devel- 
opment of a metro system case study, suggesting "rules of thumb" , modelling 
techniques and assessing the current tool support (Rodin platform [2]). 

We build a metro system model in a "top-down" style, in Event-B based on 
safety properties, starting from an abstraction view of the system and gradually 
augmented it with more details. Generic instantiation [3,4,5] and decomposi- 
tion [6] are techniques used in the case study, simplifying the formal development 
by reusing existing models and avoiding re-proofs. Some requirements are based 
on real ones for metro system carriage doors. 

A brief overview of the Event-B language is given in Section 2. The construc- 
tion of the metro system model is described in Section 3, including a discussion of 
the keys points for building of a formal model such as requirements, abstraction, 
refinement, proofs, decomposition, generic instantiation in the Rodin platform. 
We finish with conclusions and related work in Section 4. 

1 DEPLOY - Industrial deployment of system engineering methods providing high 
dependability and productivity - supported by the EU Commission (Grant 214158) 



2 Background 



Event-B is a formal modelling method for developing correct-by-construction 
hardware and software systems. An Event-B specification is divided into two 
parts: a static part called context and a dynamic part called machine. A ma- 
chine SEES as many contexts as desired. A context consists of sets, constants 
and assumptions (axioms) of the system. An Event-B model is a state transition 
system where the state corresponds to variables v and transitions are repre- 
sented by a collection of events evt in machines. The most general form of an 
event is: evt = any t where G(t,v) then S(t,v,v') end , where t is a set 
of parameters, G(t,v) is the enabling condition (called guard) and S(t,v,v') is 
a before-after predicate computing after state v' . Essential to Event-B is the 
formulation of invariants I(v): safety conditions/properties to be preserved at 
all times. Proof obligations (PO) are generated for all system transitions to vali- 
date and ensure that these conditions are preserved. Because Event-B advocates 
the use of refinement, additional PO (forward refinement) [I] are generated to 
ensure that concrete refinements preserve the abstract models' properties. The 
Event-B toolset is Rodin [2], result of an EU research project 2 : software tool, 
based on modern software programming tools created to help the development 
of specifications based on the idea that large complex or critical projects should 
start with modelling and reasoning about its specification. 

3 Case study construction 

In this section the steps followed throughout the construction of our model arc 
described. The safety-critical metro system case study describes a formal ap- 
proach for the development of embedded controllers for a metro 3 . Butler [ 
makes a description of embedded controllers for a railway using classical B. Our 
starting point is based on that work but applied to a metro system. That work 
goes as far as our first decomposition. We augment it by refining sub-components, 
adding requirements and instantiating emergency and service doors in carriages. 

3.1 Requirements 

Requirements analysis [8] in systems engineering, encompasses tasks that go into 
determining the needs or conditions to meet for a new or altered product, tak- 
ing account possible conflicting requirements of the various stakeholders, such as 
beneficiaries or users. There are several techniques to deal with requirements and 
they vary according to projects' domains. Moreover guidelines [S] have been de- 
veloped to achieve this goal. Nevertheless requirements are often described in an 
informal manner. Consequently it is hard to reason about each requirement: ex- 
perienced people are able to detect contradictions and uncertainties but it is not 

2 RODIN: Rigorous Open Development Environment for Open Systems (EU 1ST Proj) 

3 The Event-B model built is available at http://eprints.ecs.soton.ac.uk/23135/ 



guaranteed that all will be uncovered. Moreover, within the formal methods do- 
main, it is hard to trace informal requirements with the model/implementation. 

Although not available when we developed this case study, a requirement 
plug-in (ProR [9,10]) now exists for the Rodin platform, supporting ReqIF 1.0.1 
Standard 4 . Benefits of ProR are incremental creation of hierarchical require- 
ments structures from informal requirements or providing traceability between 
requirements and formal models. Furthermore, the system description, mixing 
formal and informal artefacts may contain assumptions about the environment 
or requirements properties and ProR can reason about them (possibly uncover- 
ing contradictions and uncertainties). 

Our metro system is characterised by trains, tracks circuits (also called sec- 
tions or CDV and a communication entity (comms) that allows the interaction 
between trains and tracks. The trains circulate in sections and before a train 
enters or leaves a section, a permission notification must be received. In case of 
hazard situations, trains receive braking notifications. Track is responsible for 
controlling the sections, changing switch directions (switch is a special section 
that connects different routes and can be either divergent or convergent) and 
sending signalling messages to the communication entity. These are the main 
requirements for this case study (some described in Fig. 1): 

1. Route sections are all connected and cannot have empty gaps (invl). 

2. There are no loops in the route sections: sections cannot introduce loops 
(thm3). Moreover no circularity is allowed (via transitive closure: thm4). 

3. Switches cannot be connected and can be either divergence or convergent. 

4. Non-switches have at most one successor and at most one predecessor section. 

5. Trains circulate in tracks (invA,inv5,inv7), preserving transitive closure. 

6. Trains occupy at least one section plus a safety distance (inv4). 

7. Trains cannot be in the same section at the same time (trains crashed: invlS). 

8. Comms handles messages exchanged between trains and tracks. Trains head- 
ing to an occupied section receive a negative access and braking message. 

9. As part of the safety requirements, all trains have an emergency button. 

10. While the emergency button is enabled, the train cannot speed up (braking). 

11. If a train door is opened, then the train is stopped (in a platform or due to 
an emergency). In contrast, if the train is moving, then its doors are closed. 

3.2 Abstraction 

Following a "top-down" design, the development starts with an abstraction 
model: description that encompasses the main aspects and goals the system 
intends to answer, obstructing itself from the implementation and other details. 
Getting a good abstraction is a very hard task requiring an accurate under- 
standing of the system. Moreover the abstraction is the basis of the development 
playing a crucial role in the entire model. A good abstraction is often not achieved 
at first attempt even for experienced developers. It may change throughout the 



4 ReqIF: Requirements Interchange Format - http://www.omg.org/spec/ReqIF/ 



development to fit additional requirements that came into play on a later stage 
or when, after a few refinements, it does not fit exactly as initially desired. No 
tools are available that help finding the right abstraction mainly because each 
system has its specific properties. It often relies on experience and empiric re- 
search. Nevertheless we believe that systems can be categorised according to 
some common properties, architecture and behaviours and therefore having a 
abstraction template repository could be helpful when starting a model devel- 
opment. Abstraction templates could then be customised according to specific 
needs. Unfortunately such repository does not yet exist, requiring further inves- 
tigation beyond the scope of this paper. 

For our abstraction model (Fig. I), we focus on the main properties: tracks 
are divided into sections that are connected (Reqs. 1, 2, 3, 4); trains circulate in 
tracks (Req. 5) ; the most important (safety) global property introduced initially 
states that trains cannot be in the same section at the same time (Reqs. 6, 7). 
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Fig. 1. Excerpt of MetroSystem-MO: variables and invariants 



3.3 Refinement 

Refinement allows the construction of a model in a gradual way, making it closer 
to an implementation [ ]. At same time, the overall correctness of the system 
is preserved. Our case study heavily uses refinement as seen in Fig. 2. At each 
refinement step, new requirements are introduced to the model and consequently 
new invariants, variables, events are introduced or refined. For instance, for re- 
finement Tmiri-Ml, the invariants and properties imposed are: 

1. There is a limit to the number of carriages per train. 

2. If a carriage alarm is activated, the train's emergency button is also active. 



3. The sum of carriage doors corresponds to the doors of a train. 

4. Trains have states: maintenance, manual, automatic. 

5. If a train is not in a maintenance state, then it must have the correct number 
of carriages and the leader carriage must be defined already. 

6. If a train is in maintenance, then it must be stopped. 

7. The emergency brake is activated if a train exceeds the maximum speed. 

Do it right at first/Recursion As for abstraction, refinement steps are not 
reached at first attempt. They evolve, accommodate different requirements and 
also change, impacting previous refinements. And that comes with a cost: a 
change in the abstraction, affects all the following refinements and the adjust- 
ment to each refinement level has to be done manually, which is cumbersome. 
In our case, the emergency brake requirement (Req. 9) was only added after we 
had reached the first decomposition. The consequences propagated to the ab- 
straction, impacting most events and manual reproving (which delayed for a few 
days the progress achieved before) . This is a limitation of the refinement process 
in the tool that does not propagate the changes, requiring improvements. 

3.4 Proofs and model construction 

Proofs play an important role in formal modelling, checking that properties and 
behaviours are preserved. There is always a compromise between representing a 
system, avoiding complex proofs and tool limitations. Despite the plug-ins avail- 
able for automated proof solving (AtelierB provers [11], Relevance Filter[12]), 
complex proofs tend to be avoided. From our experience, a complex proof hard 
(but not impossible) to discharge, often means that the model is overcomplicated 
and may be rewritten/simplified. When building Train-M2, train doors were rep- 
resented as (DOOR-CARRIAGE; train-carriage)' 1 , where DOOR-CARRIAGE g 
DOOR-^rC ARR1 AGE represents carriage doors and train-carriage e CARRIAGE 
-+>tms represents the train carriages. Although that relation is enough to describe 
which doors are part of a train, from a proof viewpoint was very unsuccessful. 
By rewriting train doors as variable doorJrain-carriage = (DOOR-CARRIAGE; 
train -carriage)' 1 and invariants door -train -carriage £ trns «-» DOOR, 
doordrairi-carriage' 1 £ DOOR -+> trns, we solved the issue. 

From a tool viewpoint, there is a direct relation between the number of 
PO per refinement and performance. Our criteria to choose which properties to 
add per refinement were directly related with the PO generated per refinement: 
if over 150 PO, additional properties were stated in new refinements. Train 
requirements are spread over 4 refinement steps for that reason. Improvements 
have been made in terms of tool performance in the latest releases but large 
developments (over 15 refinements and large number of events) are still affected. 

3.5 Decomposition 

The "top-down" style of development used in Event-B allows the introduction 
of new events and data-refinement of variables during refinement steps. A con- 
sequence of this development style is an increasing complexity of the refinement 



process when dealing with many events and state variables. Model decomposi- 
tion [6] addresses such complexity by cutting a large model into smaller com- 
ponents. Two methods have been identified for the Event-B decomposition and 
are supported by a Rodin plug-in [6]: shared variable [3] and shared event [13]. 
Because decomposition is monotonic [13], the generated sub-components can be 
further refined independently: sub-components can be used to further refined 
the original model or be used in other models. Moreover team development 
can be introduced: different developers can share parts of the same original 
model by working independently in parallel with the resulting decomposition 
sub-components. Decomposition also partition PO which are expected to be 
easier to discharge in sub-components. In our model, decomposition is used for 
following reasons: separation of aspects; model architectural decision; tool per- 
formance: building/proving is faster for separated models than for monolithics. 

Decomposition is recursively used as seen in Fig. 2: splitting the initial mono- 
lithic model into three parts ( Train, Middleware and Track) from an archi- 
tectural point of view (separation of aspects); splitting Train_M^ into Leader- 
Carriage (due to the number of POs and separation of aspects) and Carriage 
and later on to decompose Carriage into Carriagelnterface and CarriageDoor 
(Fig. 3(b)). Although we could have used either decomposition styles, we used 
the shared event style mainly because in that manner, we did not constrain the 
refinement of variables (like it happens for shared variables). 

Unfortunately the decomposition process does not propagate modifications 
on the original machine and consequently, decomposed components need to be 
regenerated if the original component is modified. If the decomposed compo- 
nents have been refined, than the modifications need to be reflected in those 
refinements (notified via errors or PO being generated or requiring reproving). 
We believe that the decomposition tool requires improvements in terms of prop- 
agation changes to minimise the overall impact that is inevitable. 
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Fig. 2. Overall view of the metro system development 



3.6 Generic Instantiation 



Generic Instantiation can be seen as a way of reusing components and solving 
difficulties raised by the construction of large and complex models [3] . Generic 
developments (single machine or a chain of refinements) are reused, originating 
components with similar properties instead of starting from scratch. Reusabil- 
ity occurs via the instantiation and parameterisation of patterns. [ ] proposes a 
generic instantiation approach for Event-B by instantiating machines. The goal 
is to reuse a pattern as an instance in an existing development (problem) consist- 
ing of a chain of refinement of machines Sq to Sk (S stands for Specific problem) 
as seen in Fig. 3(a). The instance sees the parameterisation context Ciq (that 









SO sees CS 






re fin i mini 




Sk se 


esCS 




^refinement 





in51antiati °i 






INSTANCE IG 




sees CIG 










► 



GoseesCGO 



Gl sees CGI 



^ Gj sees CGj 



(a) Instantiation of Go-.Gj via 
parameterisation context Gig 
creating instance IG to fit 
problem So-.Sk- 




Instance Instance Pattern 

(b) Carriage Refinement Diagram and Door In- 
stantiation 



Fig. 3. Generic Instantiation 



extends the specific problem context Cs) containing the replacement properties 
for the elements in context Cci- Variables, events and parameters can be re- 
named to fit new or existing elements in the specific problem. The correctness 
of the instantiation relies on reusing the pattern PO and ensuring that assump- 
tions in the context parameterisation are satisfied in the instance. In our case 
study, an existing development of carriage doors (GCDoor_M0..GCDoor_M2) is 
used as a pattern with all the related PO previously discharged. The pattern 
is instantiated and parameterised accordingly into emergency doors and service 
doors (Fig. 3(b)). The main pattern requirements are: 

1. Doors have a state associated: open (train must be stopped) or closed. 

2. When adding/removing a carriage to a train, doors must be closed for safety. 

3. Actions involving the doors may result from commands (open, close, isolate, 
remove-isolated) sent from the central door control. 

4. Doors must be closed and locked before a train starts moving. 



5. Doors are opened by the following devices: manual jplat form, manual-internal 
or automatic-central-door. 

6. Doors can get obstructed when closed automatically (people/object obstruc- 
tion). If an obstruction is detected, a second attempt is made to close them. 

7. Doors can be isolated in case of malfunction or for safety reasons. 

8. If a door is obstructed, then it must be in a state corresponding to open. 

These requirements are shared between both emergency and service doors 
highlighting the use of instantiation. Additional requirements for each kind of 
door can be added in further refinements (emergency doors are only available 
for emergencies, do not respond to standard open command, etc). For our case, 
the instantiation was manual. Nevertheless currently a generic instantiation pro- 
totype is available [5]. The tool needs to mature and requires improvements in 
terms of matching the pattern and the last refinement of problem. In this case 
study, the matching was manually achieved through decomposition. 



Animation/Model Checker and Code Generation Although we are mainly 
interested in safety properties, ProB model checker [14] proved to be a very useful 
tool. At some stages, all PO were discharged but ProB showed that the system 
was deadlocked. In larger developments, these situations may occur frequently. 
Therefore we suggest safety properties preservation (via PO) and running ProB 
to confirm deadlock freeness. Another option, to be addressed by ADVANCE 5 is 
to introduce liveness properties (e.g. enabledness). Regarding implementation, a 
code generation plug-in 6 [15] (Event-B to Ada or C) is available. 



Statistics Table 1 describes the statistics of the model in terms of variables, 
events and PO (including automatically discharged) for each refinement. Al- 
most 3/4 of the PO were discharged automatically. The case study conditions 
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Table 1. Statistics of the metro system case study 



5 ADVANCE project: Advanced Design and Verification Environment for Cyber- 
physical System Engineering- http://www.advance-ict.eu/ 

6 Code generation plug-in: http://wiki.event-b.org/index.php/Code_Generation 



were the following: Rodin v2.1 (Auto Builder: OFF; Auto Prover: OFF), Model 
Decomposition vl.2.1 and Shared Event Composition plug-in vl.3.1, Generic 
instantiation was done manually (tool support was not available), ProB v2.1.2. 

4 Related Work and Conclusions 

From the experience of developing formal models involving a large number of re- 
finements, development tools reach a saturation point where it is not possible to 
edit the model due to the high amount of resources required (or very slowly). De- 
composition is a possible solution that alleviates the issue by splitting the model 
into tool manageable dimensions, separating concerns, decreasing the number 
of events and variables per sub-component which results in more manageable 
models. Generic instantiation reuses pattern and respective PO per instance. 

The experience of modelling a metro system in Event-B using the Rodin 
platform and its plugins, is shared in terms of model design and assessment 
of available tools. Requirements are defined and modelled through refinement. 
As an architectural decision and to alleviate the problem of modelling a mono- 
lithic component, the model is decomposed several times. Benefiting from an 
existing development for carriage doors GCDoor, this pattern is used to instan- 
tiate two kind of carriage doors: service and emergency doors. The refinement 
of Carriage is decomposed, originating CarriageDoor that matches with pattern 
GCDoor_M0. Although the instantiation is similar for both cases, the resulting 
instances can be further refined independently Generic instantiation minimises 
the proving effort reusing the pattern GCDoor PO (in the overall 257). Therefore 
we achieve our goal of reusing existing developments and discharging as little 
PO as possible. Even the interactive proofs were relatively easy to discharge 
once the correct tactic was discovered. This task would be more difficult with- 
out decomposition due to the elevated number of hypotheses to be considered. 
Nevertheless the effort of discharging PO could be further minimised by having 
an easy way to reuse PO tactics. A limitation of this model is not addressing 
liveness properties through proofs which would enrich the model. 

Although we use Event-B, these techniques are generic enough to suit other 
formal notations and other case studies. Formal methods has been widely used 
to validate requirements of real systems. The systems are formally described 
and properties are checked to be preserved whenever a system transition occurs. 
Usually this result in complex models with several properties to be preserved, 
therefore structuring and reusability are pursued to facilitate the development. 
Lutz [] 6] describes the reuse of formal methods when analysing the requirements 
and designing the software between two spacecrafts' formal models. Stepney et 
al. [17] propose patterns to be applied to formal methods in system engineering. 
Using the Z notation, several patterns (and anti-patterns) are identified and 
catalogued to fit particular kind of models. These patterns introduce structure to 
the models and aim to aid formal model developers to choose the best approach 
to model a system, using some examples. Although the patterns are expressed 
for Z, they are generic enough to be applied to other notations. Comparing with 



the development of our case study, the instantiation of service and emergency 
doors corresponds to the Z promotion, where a global system is specified in 
terms of multiple instances of local states and operations. Although there is 
not an explicit separation of local and global states in our case study, service 
and emergency doors states are connected to the state of CarriageDoor and 
we even use decomposition, instantiation and refactoring to fit into a specific 
pattern. Stepney [17] suggests template support and architecture patterns to be 
supported by tools. We agree and aim to address this issue in the future by 
having categorised templates customised according to the modeller's needs. 
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